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C++ Conference Program 

Denver Marriott, City Center Hotel 
Denver, Colorado 

October 17-20, 1988 

USENIX is holding its first full C++ conference in Denver, Colorado, Monday through Thursday, 
October 17-20. 

Program At A Glance/Dates to Remember 

• Hotel Registration Deadline September 26 

• Pre-registration Deadline September 28 

• All Day Tutorials October 17-18 

• Technical Sessions October 19-20 

For details about registration, contact the USENIX Conference Office immediately. 

C++ Tutoral Program 


Ml: 

Advanced C++ Topics 

Jonathan Shopiro, AT&T Bell Laboratories 

Monday, 9-5:00 

M2: 

Object-Oriented Development and C++ Concepts 

John Cardan and Adrienne Dockrell, Glockenspiel Ltd. 

Monday, 9-5:00 

Tl: 

An Introduction to C++ 

Robert Murray, AT&T Bell Laboratories 

Tuesday, 9-5:00 

T2: 

Applications: Interviews & C++ 2.0 

Tuesday, 9-5:00 


Part A: Programming User Interfaces in C++ With Interviews 
Mark A. Linton, Stanford University 
Part B: What’s New in C++ 2.0 

Stanley Lippman, AT&T Laboratories 

Opening Session Wednesday, 9-10:30 

Keynote speech 

W. N. Joy, Sun Microsystems 

Parameterized Types for C++ 

Bjarne Stroustrup, AT&T Bell Laboratories 

Technique Wednesday, 11-12:30 

Building Well-behaved Type Relationships in C++ 

R. B. Murray, AT&T Bell Laboratories 

Porting from Common Lisp with Flavors to C++ 

Joseph Eccles, AT&T Bell Laboratories 

Databases and File Systems Wednesday, 2-3:30 

Prototyping Database Applications with a Hybrid of C++ and a 4GL 
Ronan Stokes, Glockenspiel, Ltd. 

Open Dialogue: Using an Extensible Retained Object Workspace to Support a UIMS 
Andrew Schulert, Kate Erf, Apollo Computer 
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Building Object-Oriented UNIX-like File Systems in C++ 

Peter Madany, Doug Leyens, Vince Russo, 

Roy Campbell, University of Illinois 

Applications 

Applying Object-Oriented Design to Structured Graphics 

John M. Vlissides, Mark A. Linton, Stanford University 

A C++ Interpreter for Scheme 

Vincent F. Russo, Simon M. Kaplan, University of Illinois 

GPIO: Extensible Objects for Electronic Design Tools 
David Campbell, RuSsel Edwards, Prakash Reddy, 

Roger Scott, Data General Corporation 

Experience 

C++: From Research to Practice 

S. B. Lippman, B. E. Moo, AT&T Bell Laboratories 

NAPS - A C++ Project Case Study 
C. Berman, R. Gur, AT&T 

Parallelism and Simulation 

Data-Level Parallel Programming in C++ 

Thomas M. Breuel, MIT 

A Multiprocessor Operating System Simulator 

Gary M. Johnston, Roy H. Campbell, University of Illinois 

Modelling of Control Systems with C++ and PHIGS 
Dag M. Briick, Lund Institute of Technology 

Linguistics 

Type-safe Linkage for C++ 

Bjarne Stroustrup, AT&T Bell Laboratories 

Implementing a Logic-Based Executable Specification Language in C++ 
Peter A. Kirslis, Robert B. Terwilliger, AT&T Bell Laboratories 

Debugging and Instrumentation of C++ Programs 
Martin J. O’Riordan, Glockenspiel, Ltd. 


Libraries 

libg++, The GNU C++ Library 
Douglas Lea, SUNY Oswego 

A Class Library for Darts 

Troy Otillo, Cal Poly - SLO 

Guide to the C++ Real Library 

Jerry Schwarz, AT&T Bell Laboratories 

Iris: A Class-Based Window Library 

E. R. Gansner, AT&T Bell Laboratories 


Wednesday, 4-5:30 


Thursday, 9-10:30 


Thursday, 11-12:30 


Thursday, 2-3:30 


Thursday, 4-5:30 
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Call for Papers 

Winter 1989 USENIX Conference 

San Diego, California 
January 30 - February 3, 1989 


Papers are requested for formal review as 
candidates for inclusion in the three day tech¬ 
nical session at the 1989 Winter USENIX 
Conference. Papers that are accepted will be 
presented at the conference and published in 
the conference proceedings. The technical ses¬ 
sions provide a forum for the presentation of 
new research and development related to or 
based upon the UNIX operating system. 

Suggested topics include (but are not 
limited to): 

• Performance analysis and tuning 

• New User Interfaces and Applications 

• System and Network Security 

• Networking and Distributed Services 

• RISC versus CISC in UNIX 

• Software and System Management tools 

• Standards 

• Graphics and Electronic Publishing 

• Evolution of UNIX for the 1990’s 

All papers should describe new and 
interesting work. Acceptance or rejection of a 
paper will based completely on the work 
submitted at the deadline. Submitted papers 
should consist of a 100 to 300 word abstract in 
addition to the main body of the paper. 
Extended abstracts will be conditionally 
accepted but full papers are preferred. Papers 
accepted on extended abstracts that do not 
meet the promise of the abstract will be 
rejected. Each paper should discuss how this 
work relates to prior work and provide 
sufficient detail in the presentation of back¬ 
ground material and work to allow referees to 
perform a consistent comparison to other 
submitted papers. Concise references of 
related work should also be included as 
appropriate. Full papers should be 6-12 single 
spaced typeset pages and include any abstract, 
references, or illustrations. For the review 
process you should submit the highest quality 
copy you can create. Laser printer output is 
recommended. The exact format for final 
papers will be sent to authors of accepted 
papers. 


Four hard copies and one electronic copy 
of each submitted paper must arrive no later 
than October 7, 1988; this is an absolute dead¬ 
line. Papers received after that date will not 
be considered. Papers which clearly do not 
meet USENIX’s standards for applicability, 
originality, completeness or page length may 
be rejected with no review. Authors will 
receive official notification no later than 
November 4, 1988, and final papers are due by 
December 5, 1988. 

Please contact one of the program chairs if 
additional information is required: 

Greg Hidley, (619) 534-6170 
Keith Muller, (619) 534-4062 

They may be also be reached at 
sdusenix@ucsd . edu . 

Send technical program submissions to: 

Greg Hidley 
CSE Dept. C-014 

University of California, San Diego 
La Jolla, CA 92093 

Bitnet: sdusenix@ucsd 

Internet: sdusenix@ucsd.edu 
uucp: ucbvax!ucsd!sdusenix 


The program committee includes: 


Rick Adams 
Keith Bostic 
Todd Brunhoff 
John Chambers 
Lori Grob 
Andrew Hume 
Thomas Narten 
Don Seeley 
Melinda Shore 

Gene Spafford 
Henry Spencer 
Avadis Tevanian 
Karen White 


Center for Seismic Studies 
UC Berkeley 
Tektronix 

University of Texas, Austin 
NYU 

AT&T Bell Labs 
Purdue University 
University of Utah 
Frederick Cancer 
Research Facility 
Purdue University 
University of Toronto 
NeXT 
Pyramid 
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Workshop on Large Installation Systems Administration 

DoubleTree Hotel 
Monterey, California 

November 17-18, 1988 


In light of last year’s successful workshop on Large Installation Systems Administration, 
Alix Vasilatos will again be chairing a workshop on this subject in Monterey, CA on Thurs¬ 
day and Friday, November 17th and 18th, 1988. There is demonstrable benefit in bringing 
together system administrators of sites with 100 or more users (on one or more processors) 
to compare notes on solutions that they have found for a variety of common problems. 
These include but are not limited to: 

Large file systems (dumps, networked file systems) 

Password file administration 
Large mail system administration 
USENET/News/Notes administration 

Heterogeneous environments (mixed vendor and/or version) 

Load control and batch systems 
Monitoring tools 

Software release to multiple systems 
Output device management 

The workshop will focus on short papers and presentations. You do not have to 
present to attend! Proceedings will be available at the workshop. 

Rob Kolstad of Prisma Computers will be the Keynote Speaker. His topic will be “The 
Evolving Role of the System Administrator.” 

For details about registration, contact the USENIX Conference Office at (213) 592-3243 
or { uunet, ucbvax } !usenix!judy. 
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Call for Papers 
EUUG Spring ’89 Conference 

Brussels, Belgium 
April 10-14, 1989 


The BUUG will host the Spring ’89 European UNIX systems User Group Technical Conference 
in Brussels. Technical tutorials on UNIX and closely related subjects will be held on Monday and 
Tuesday, followed by the three day conference with commercial exhibitions. A pre-conference regis¬ 
tration pack will be mailed to interested persons in early December. 

Call for Papers 

The EUUG invite abstracts from those wishing to present their work. Submissions from 
students are particularly encouraged under the EUUG Student Encouragement Scheme, details of 
which are available from the Secretariat. All submitted papers will be refereed to be judged with 
respect to their quality, originality and relevance. Abstracts must be submitted by post to the EUUG 
Secretariat. All submissions will be acknowledged. Suggested subject areas include: 


• real time 

• networking 

• security issues 

• graphics 

• internationalisation 

• distributed processing 


• fault tolerance 

• new architectures 

• transaction processing 

• window systems and environments 

• supercomputing 

• standards and conformance tests 


Important Dates: 


Abstract deadline 
Acceptance notification 
Final paper received 

Tutorial Solicitation 


November 30, 1988 
January 15, 1989 
February 1, 1989 


Tutorials are an important part of the EUUG’s biannual events, providing detailed coverage of a 
number of topics. Past tutorials have been taught by leading experts. Those interested in offering a 
tutorial should contact the EUUG Tutorial Officer as soon as possible. 

Additional Information 

The Programme Chair will be pleased to provide advice to potential speakers. 

If you wish to receive a personal copy of further information about this, and future, EUUG 
events, please contact the Secretariat. 


Secretariat 

EUUG 

Owles Hall 

Owles Lane 

Buntingford 

Herts, SG9 9PL, UK 

Phone: +44 763 73039 
Fax: +44 763 73255 

Telex: 

Email: euug@inset.uucp 


Tutorial Officer 

Neil Todd 
1ST 

60 Albert Court 
Prince Consort Road 
London, SW7 2BH, UK 

+44 1 581 8155 
+44 1 581 5147 
928476 ISTECH G 
neil@ist.co.uk 


Programme Chair 

Prof. Marc Nyssen 
Medical Informaticas Dept. 
Vrije Universiteit Brussel 
Laarbeeklaan 103 
B-1090 Jette Belgium 

+ 32 2 477 44 24 
+ 32 2 477 40 00 

marc@minf.vub.uucp 
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Obtaining GNU Software 

The GNU Project (GNU’s Not UNIX) is developing a complete UNIX compatible software 
system with freely redistributable source code. The rationale for GNU is explained in the GNU 
Manifesto. Copies are available in the GNU Emacs distribution and manual, and by request to 
gnu@prep.ai.mit. edu. 

You are encouraged to get GNU software from or with others. GNU software is also available by 
ftp on the DoD/NSF Internet, and by uucp\ ask gnu@prep for details. If you are unable to use one of 
these methods, you can use this order form. 


at $ 150 = $_ GNU Emacs source code and other software, on 1600bpi tape in tar format. 

The tape also includes Scheme, T, Hack, Bison, GNU Chess, GDB, and 
the X window system (Version 10r4). 

at $ 150 = $_ GNU C Compiler. Beta test tape, 1600bpi, in tar format. The tape also 

includes Bison, Gawk, GNU Assembler, X windows (Version llr2 
complete), Flex, GNU Make, and object file utilities. 

at $ 175 = $_ GNU Emacs source and other software, cartridge tape for Suns. 

_at $ 175 = $_ GNU C Compiler and other software, cartridge tape for Suns. 

_at $ 150 = $_ GNU Emacs source and binary code, on 1600bpi tape in VMS interchange 

format. 

_ at $ 150 = $_GNU C Compiler source and binary code, on 1600bpi tape in VMS 

interchange format. 

at $ 15 = $_ GNU Emacs manual, ~300 pages, spiral bound. The manual is 

phototypeset and offset printed, and includes a reference card. 

at $ 60 = $_Box of six GNU Emacs manuals, each with reference card. 

at $ 1 = $ __ GNU Emacs reference card. 

at $ 5 = $_Packet of ten GNU Emacs reference cards. 

_at $ 10 = $_ GDB manual, ~50 pages, side stapled. 

_at $ 10 = $ __ Texinfo manual, ~100 pages, side stapled. 

_at $ 10 = $ ___ Termcap manual, ~60 pages, side stapled. 

Sub Total $__ 

$_ 5% Massachusetts sales tax, if applicable. 

$_Optional tax deductible donation. 

$ _____ Outside North America and Hawaii, add $ 15 for each tape or manual for 
shipping costs; and add $60 for each box of manuals. 

Total $_ 


Prices are subject to change without notice. All software from the Free Software Foundation is 
provided on an “as is” basis, with no warranty of any kind. TeX source for all manuals is on the 
appropriate distribution tape. Many of these programs are covered by a General Public License that 
permits everyone to have and run copies of them, at no charge, and to redistribute copies under cer¬ 
tain conditions which are designed to make sure that that all modified versions of the program 
remain as free as the versions we distribute. The General Public License is usually in a file named 
COPYING. 

Orders are filled upon receipt of check or money order. We do not have the staff to handle the 
billing of unpaid orders. Please help keep our lives simple by including your payment with your 
order. Make checks payable to “Free Software Foundation,” and mail orders to: 

Free Software Foundation 

675 Mass. Avenue 
Cambridge, MA 02139 
+ 1 (617) 876-3296 

The USENIX Association is printing the above as a service to the user community; no endorsement of GNU software 
is implied. 


Name: _ 

Organization: _ 

Address: ___ 

City, State, Zip:_____ 
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Broadcast Storms, Nervous Hosts, and Load Imbalances 

Paul E. McKenney 

Information Sciences and Technology Center 
SRI International 


ABSTRACT 

As equipment connected to local-area networks becomes more complex and diverse, so 
do possible modes of failure. Innocent-looking “features” of such equipment can easily 
cause serious disruptions of service to a local-area network. 

Some software problems (including broadcast storms, “nervous hosts,” and load imbal¬ 
ances) that can arise on Ethernets using the DDN protocol suite are examined herein. The 
causes of these problems and the sequence of events leading up to them are explored in 
detail, and some commonly known methods of preventing, diagnosing, and correcting the 
problems are presented. 


Overview 

This paper will look at three of the types 
of problems which afflict local-area networks: 

• Broadcast storms 

• Nervous hosts 

• Load imbalances. 

The following sections will look at these 
problems in some detail, describing their 
causes, how they can be diagnosed, and how 
they can be prevented or corrected. Since the 
broadcast storm is the most complex and the 
most damaging of these problems, it will be 
described in considerably more detail. 

Broadcast Storms 

While a classic broadcast storm occurs 
when a large number of hosts respond almost 
simultaneously to a broadcast packet, the 
effects of a broadcast storm (nearly total denial 
of network services for an extended period) 
can be induced by a number of mechanisms. 
The term “broadcast storm” will used in this 
more general sense for the rest of this paper. 

Broadcast storms can be caused by 
continual packet transmission and by 
inappropriate responses to broadcast packets. 


Continual Packet Transmission 

Since Ethernet is multiple-access, there is 
nothing to prevent a host from consuming 
most of an Ethernet cable’s bandwidth by 
continually transmitting garbage packets. This 
extreme case can be remedied only by either 
fixing the software or physically disconnecting 
the host from the Ethernet. 

Note that bugs that cause continual packet 
transmission can occur in user software just as 
easily as they can in the kernel. A normal user 
program on a Sun-3 work station can easily 
send well over 100 packets per second through 
a UDP socket. As few as five or ten programs 
doing this simultaneously on separate work 
stations (e.g., rwhod ] ) can do a very good job 
of congesting an Ethernet. 

The Ethernet source address is relatively 
immune to corruption by software bugs 
because it is usually stored in a hardware regis¬ 
ter in the Ethernet interface. 2 Therefore, keep¬ 
ing a list of the Ethernet addresses of all 
machines on a network can help pinpoint the 


1 This program periodically broadcasts the list of users 
currently logged onto the host that it is running on. While 
this allows users to easily see who is logged onto other 
machines, it can also produce bursts of heavy traffic. 

2 The Ethernet source address is not always completely im¬ 
mune to corruption. For example, hosts running 
DECNET set their Ethernet addresses to a value related to 
their DECNET node ID under software control. 
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source of garbage packets. This pinpointing is 
accomplished by extracting the Ethernet source 
address from the garbage packet (possibly 
using Van Jacobson’s tcpdump program), then 
looking up the source address in the list to find 
the offending host. For those who do not wish 
to maintain such a list manually, we at SRI 
have written an “etherhostprobe” program 
that makes a list of Internet addresses and 
Ethernet addresses of all hosts connected to 
the local Ethernet that implement address 
resolution protocol (ARP). 

Responding Inappropriately to Broadcast 
Packets 

The classic broadcast storm ensues when 
several hosts attempt to forward the same 
datagram over the broadcast medium it came 
from. 

A classic broadcast storm involves 
Internet protocol (IP) packets and ARP 
packets. IP packets are the building blocks for 
the familiar transmission control protocol 
(TCP), network file system (NFS), and remote 
procedure call (RPC). ARP packets allow hosts 
to associate Internet addresses with the 
corresponding Ethernet addresses. 

The following sections will describe a 
classic broadcast storm in more detail by look¬ 
ing first at the formats of the IP and ARP 
packets, second at the IP forwarding 
mechanism, and finally at a (small) example of 
a classic broadcast storm. This will be 
followed by some experimental results 
obtained at SRI and by recommendations for 
preventing classic broadcast storms. 

Ethernet Header Format 

All packets on an Ethernet (including IP 
and ARP packets) have an Ethernet header 
prefixed to them as follows: 

• Six-byte source address 

• Six-byte destination address 

• Two-byte packet type. 

An Ethernet address is typically written in 
hexadecimal form, separated by colons, e.g., 
1c:08:1e:3d:00:0a. The Ethernet broadcast 
address is ff :ff :ff :ff :ff :ff; a packet with 


this as its destination address will be received 
by all local Ethernet interfaces. 

Each Ethernet interface ignores all packets 
except those whose destination address is 
either that Ethernet interface’s address or the 
broadcast address. Ethernet packets destined 
for the broadcast address form the seeds of a 
broadcast storm. 

An Ethernet packet type of 0800 
(hexadecimal) indicates that the packet is an 
IP packet; an Ethernet packet type of 0806 
(hexadecimal) indicates that the packet is an 
ARP packet. 

IP Header Format 

An IP packet has many fields, but the only 
one relevant to this discussion is the four-byte 
IP destination address (see Request For Com¬ 
ments (RFC) 791 for more details). An IP 
address is typically written in dotted-decimal 
form, e.g., 10.0.0.51. Each IP address is 
divided into a “network part” and a “host 
part” with the latter part broken down further 
in a subnetted network (see RFCs 922, 950, and 
1027 for details). Table 1 shows how the 
different classes of nonsubnetted IP addresses 
are decomposed into network and host parts. 


First Byte 

Class 

Network 

Host 

0 

127 

A 

i 

3 

128 

191 

B 

2 

2 

192 

223 

C 

3 

1 

224 

239 

D 



240 

255 

E 




Table 1: IP Address Classes 


Class D addresses are special multicast 
addresses (see RFCs 966 and 988), and Class E 
addresses are reserved for future use. Only 
Class A, B, and C addresses are relevant to 
this discussion. (See RFCs 1010 and 1020 for 
more details on IP address assignment.) 

If the host part of the IP address is 
composed of all 255s (for example, 
10.255.255.255), the IP packet is to be 
broadcast to all hosts on network 10. 3 
Unfortunately, this convention was established 


3 However, since network 10 does not support the notion 
of broadcast, this IP packet would be ignored, although an 
error might be returned via an ICMP packet. 
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only fairly recently, so that some older imple¬ 
mentations (in particular BSD 4.2) employ the 
convention that a host part composed of all Os 
(e.g., 10.0.0.0) indicates that the IP packet is 
to be broadcast to all hosts on the network. 
As will be seen, this historical incompatibility 
constitutes the trigger that sets off the classical 
broadcast storm. 

A sample new-style IP broadcast packet 
layered over Ethernet is shown in Table 2. 
The “IP data” would consist of the headers 
and data of the higher level protocol (e.g., user 
datagram protocol, or “UDP”) that is layered 
on top of IP in this packet. 

ARP Packet Format 

The following fields from an ARP packet 
are relevant to this discussion (see RFC 826 for 
more details): 

• Sender’s Ethernet address 

• Sender’s IP address 

• Target’s IP address. 

A typical ARP packet might be as as shown in 
Table 3. Here the host (call it Host A) whose 


IP address is 193.30.20.10 wants to know 
the Ethernet address for the host (call it Host 
B) whose IP address is 193.30.20.11. Since 
Host A does not know Host B’s Ethernet 
address, the Ethernet destination address is set 
to the broadcast address to so that Host B can 
receive the packet. When Host B does receive 
the packet, it will note that the target IP 
address in the packet matches his own IP 
address, and will send a reply. Any other host 
that receives the packet will see that the target 
IP address in the packet does not match his 
own, and so will discard the packet. 

IP Packet Forwarding 

While an Ethernet interface can simply 
ignore packets that are not addressed to it, a 
host may be required to process IP packets 
that are addressed to someone else. For exam¬ 
ple: 

• A host that is acting as a gateway between 
two networks must forward packets between 
the networks. 

• A host that cannot forward a packet may 
inform the packet’s originator by means of an 



Field 

Value 

Ethernet Header 

Source Address 
Destination Address 
Packet Type 

1c:08:1e:3d:00:0a 
ff:ff:ff:ff:ff:ff 
0800 

IP Header 

Destination IP Address 

193.30.20.255 

IP Data 



Table 2: New-Style IP Broadcast Packet 


Field 

Value 

Ethernet Header 

Source Address 

Destination Address 

Packet Type 

1c:08:1e:3d:00:0a 
ffiff iff iff iff iff 
0806 

ARP Packet 

Sender’s Ethernet Address 
Sender’s IP Address 
Target’s IP Address 

1c:08:1e:3d:00:0a 

193-30-20-10 

193-30-20-11 


Table 3: ARP Packet 
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Internet control message protocol (ICMP) 
packet. 

A host must be very careful with packets 
that are not addressed to it. (See RFC 1009 for 
a fairly thorough discussion and RFCs 1015 
and 1017 for some recent thoughts.) 

A host must be even more careful with 
packets that have been broadcast, as they may 
have been received by many other hosts. A 
good principle is to never do anything with a 
broadcast packet unless a hundred and one 
hosts can do it at the same time safely on the 
same Ethernet. 4 Broadcast storms can occur 
when this principle is violated. 

Both BSD 4.2 and BSD 4.3 violate this 
principle by refusing to check that the Ethernet 
destination address is the same as the Ethernet 
broadcast address (ff:ff:ff:ff:ff:ff). 
Both BSD 4.2 and BSD 4.3 do check the 
Internet destination address to determine 
whether it matches their idea of the Internet 
broadcast address (in fact BSD 4.3 checks the 
Internet destination address to see whether it 
matches any of the currently known Internet 
broadcast addresses), but there is no guarantee 
that 

• It will not be necessary to add yet another 
Internet broadcast address at some time in the 
future, or that 

* Some bug that wraps a broadcast Ethernet 
header around a single-destination Internet 
packet will not crop up somewhere. 

Any check of the link layer (Ethernet in 
this case) broadcast address must be done at 
that layer; the results of the check must be 
available to the network layer (IP in this case), 
so that the layer interface would have to be 
modified to implement this check. This could 
go a long way toward explaining any 
reluctance the BSD 4.3 maintainers might feel 
about making this sort of modification. 

There is a work-around for BSD 4.2 and 
BSD 4.3 systems in the form of a kernel vari¬ 
able called ipforwarding . Setting this variable 


4 Some examples of safe actions would be recording the 
packet on a local disk, responding to the packet if no other 
host is going to (e.g., if you are the only boot server, then 
you may respond to broadcast requests for booting), and, 
of course, discarding the packet. 


to 0 will prevent any forwarding of IP packets. 
This has the (possibly unfortunate) side effect 
of making the system incapable of acting as a 
gateway between two networks or subnets. 
Stock systems have this variable set to 1 by 
default (thus enabling IP forwarding), although 
a BSD 4.3 system with a single network 
interface will behave as though it were set to 0 
(thus disabling IP forwarding). 

A Classical Broadcast Storm 

We now have the background to examine 
an example broadcast storm. Consider a small 
network with a single BSD 4.3 machine 
(193.30.20.10) whose IP broadcast address 
has been set to the standard 193.30.20.255, 
and three BSD 4.2 machines, all of which have 
ipforwarding set to 1. Referring to Figure 1 we 
see the following sequence of events: 

1. At time=0, host 193.30.20.10 broad¬ 
casts an IP packet over the network. This 
packet might look like the one in Table 2. 

2. BSD 4.2 hosts 193.30.20.11, 
193.30.20.12, and 193.30.20.13 all receive 
this packet. 

3. Since the IP destination address 
193.30.20.255 does not match either 
193.30.20.0 (the BSD 4.2 broadcast address) 
or the hosts’ own IP addresses, each host 
decides to forward the packet. 

4. Each host looks in its cache of IP-address- 
to-Ethernet-address translations for the 
Ethernet address corresponding to 
193.30.20.255. Since there is no such host, 
the lookup will fail. Each host will therefore 
broadcast an ARP packet over the Ethernet at 
time=10 in an attempt to find the Ethernet 
address corresponding to 193.30.20.255. 
Table 4 shows what this packet might look like 
for host 193.30.20.11. The three simultane¬ 
ous ARP packets collide and are therefore lost. 
Each of the hosts detects the collision, and 
schedules a retransmission at some random 
time in the future. 

5. At time=30, hosts 193.30.20.11 and 
193.30.20.13 retransmit. Again the ARP 
packets collide, are lost, and the hosts schedule 
a random retransmission. 
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Field 

Value 

Ethernet Header 

Source Address 

1c:08:1e:3d:00:0b 


Destination Address 

ff:ff:ff:ff:ff:ff 


Packet Type 

0806 

ARP Packet 

Sender’s Ethernet Address 

1c:08:1e:3d:00:0b 


Sender’s IP Address 

193.30.20.11 


Target’s IP Address 

193.30.20.255 


Table 4: Broadcast Storm ARP Packet 


6. This time, all three hosts pick different 
times to retransmit their ARP packets. Since a 
collision is therefore avoided, the packet is 
broadcast successfully to all other hosts on the 
Ethernet. 

7. Since there is no actual host with an IP 
address of 193.30.20.255, there is no reply 
to the ARP packets. Thus, all three of the 
hosts receiving the original broadcast IP packet 
will time out and drop the packet. 

The net effect is that one broadcast packet 
has caused no fewer than eight separate 
transmissions. 

We at SRI conducted larger-scale tests of 
the classical-broadcast-storm mechanism on 
our local Ethernet (after hours, of course), 
which is populated by a large diverse popula¬ 
tion of hosts, including over one hundred Sun 
workstations, several Vaxes running BSD 4.3, 
several more Yaxes running VMS, some Xerox 
workstations, several IBM PCs, several UNIX 
machines, and an IBM mainframe. 

The broadcast storm was triggered by a 
burst of rwhod packets broadcast on the new- 
style (all Is) broadcast address by a Silicon 
Graphics work station. The first set of trials 
used a total of 43 ipforwarding hosts; each trial 
generated over 400 packets per second for a 
period of twenty seconds. 

The second set of trials used a total of 23 
ipforwarding hosts; each of these trials 
generated over 400 packets per second for a 
period of ten seconds. Decreasing the number 
of ipforwarding hosts shortens the duration of 
the broadcast storm commensurately. 

The packet rate figures are subject to large 
errors because of missed interrupts in the 
measuring hosts and to high collision rates on 


the Ethernet. The figures given above almost 
certainly understate the actual packet rates. 

The standard measures for preventing 
classical broadcast storms are well known, but 
bear repeating: 

• Clear the ipforwarding kernel variable in 
each UNIX host on the network, or 

• Upgrade each system to a version that has 
BSD 4.3 networking. 

If you have a BSD 4.3 system with more than 
one network interface, it is still wise to clear 
the ipforwarding kernel variable (unless is is 
really needed as a gateway). 

Most BSD 4.2 and BSD 4.3 systems can be 
patched with adb to clear the ipforwarding 
variable as follows: 

cp /vmunix /vmunix.save 
adb -w /vmunix 
_ipforwarding?*W 0 

$q 

/etc/reboot 

Note that the change will not take effect until 
after the reboot. 

SRI experimented with an ipforwarding 
program that can determine whether a host 
will forward new-style IP broadcast packets. 
This program must be run on a Sun 5 that is 
connected to the same subnet as the host to be 
tested. This program works by handcrafting a 
“tickler” IP packet with a single-destination 
Ethernet header and an new-style broadcast IP 
header (see Table 5). After sending this 
packet, the program listens for an ARP packet 
requesting the Ethernet address that 
corresponds to the new-style IP broadcast 


5 The program uses Sun’s network interface tap (NIT) to 
send and receive raw Ethernet packets. 
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Field 

Value 

Ethernet Header 

Source Address 

1c:08:1e:3d:00:0a 


Destination Address 

1c:08:1e:3d:00:0b 


Packet Type 

0800 

IP Header 

Destination IP Address 

193.30.20.255 


Table 5: IP-Forwarding “Tickler” Packet 


address. If such a packet is heard, this means 
that the destination host does forward new- 
style broadcast IP packets. 

Note that this program does not induce a 
broadcast storm, since it “tickles” hosts one at 
a time. 

Other Packet-Response Storms 

There are other mechanisms that theoreti¬ 
cally can result in a packet-response storm: 

• Many reverse ARP (RARP) servers serving 
the same Ethernet address 

• Many network mask request servers serv¬ 
ing the same subnet. 

In practice, only a few servers (perhaps one or 
two) would be configured to serve the same 
hosts, so any “storms” that did occur would 
likely be very mild or completely unnoticeable. 

We at SRI run a script based on Van 
Jacobsen’s tcpdump program that captures 
broadcast traffic, retaining the individual 
broadcast transactions for one hour. This 
record is very helpful in ascertaining the cause 
of a broadcast storm, as one can look at the 
past hour’s broadcast packets and see which 
machines have participated in the storm and 
possibly which machine caused it. 

Nervous Hosts 

A “nervous host” is one that continually 
attempts to send packets to another host that 
is down. Since the first step in sending a 
packet to another host on an Ethernet is to 
broadcast an ARP packet, a large number of 
nervous hosts can result in an unusually large 
number of broadcast packets. 

The classic “nervous host” is a UNIX host 
set up to print on a printer that is down and is 


connected directly to the network. Let us 
assume that the printer has been down for a 
long time, and that the host has not attempted 
recently to send a job to that printer. 

Then let us also assume that a user queues 
a print job for the dead printer. As long as the 
printer is down, the host will repeat the follow¬ 
ing: 

1. The printer daemon ( Ipd) will notice that 
there is a job to be printed and will initiate the 
filter process specified in the printcap entry for 
the printer. 

2. The filter process will attempt to open a 
network connection to the printer; since the 
printer is down, this attempt will fail. 

3. The filter process will notify the printer 
daemon of the failure. However, since the 
printer could come back up at any time, the 
filter process will indicate that this is a 
temporary failure. Therefore, the printer 
daemon will retry the print job. 

Since the printer daemon must do several 
disk accesses in order to start printing a job, a 
very large number of nervous hosts would be 
necessary to affect the Ethernet significantly. 
However, the considerable volume of broad¬ 
cast ARP packets can confuse monitoring 
programs (to say nothing of people!). 

A good way to diagnose this problem is to 
look at a record of broadcast packets. If many 
of these packets are ARP requests for a printer, 
it is likely that the printer is down and that 
there are nervous hosts trying to access it. 

The best way to solve this particular 
problem is to fix your printer, but applications 
should use sleep(l) where necessary to prevent 
this problem. 
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Load Imbalances 

A load imbalance occurs on local-area net¬ 
works that consist of several Ethernet segments 
connected by bridges or gateways when: 

• One of the segments has much more traffic 
than the others, or 

• Most of the traffic on one of the segments 
is not local to that segment. The configuration 
shown in Figure 2 allows only a single packet 
at a time to be transmitted between a work 
station and its server. Much better results 
may be obtained by running parallel Ethernet 
cables to split the load, as shown in Figure 3. 
This configuration allows up to two packets to 
be transmitted at a time, for example, file 
server A could transmit a packet to one of its 
work stations at the same time that file server 
B is transmitting a packet to one of its work 
stations. 

In general, pairs of hosts that 
communicate with each other heavily should 
be placed on the same Ethernet segment. 


Running physically parallel Ethernet cables 
allows hosts to be moved easily from one cable 
to another, as required by changing patterns of 
usage. 

Note that the load balancing problem may 
be alleviated by the advent of higher-speed 
networks, such as the 100 Megabit FDDI, 
although usage will almost certainly expand to 
fill the available bandwidth. 

Summary 

In short, to keep your network healthy, 
rwhod and ipforwarding must be disabled (even 
on BSD 4.3 systems, if they have more than 
one network interface) and the network load 
must be distributed with care. 

The reader should keep in mind that the 
forgoing discussion is by no means exhaustive. 
There are many more interesting problems in 
the form of subnets, gateways, routing 
protocols, and other elements of network 
architecture and operations. 
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TIME 

0 "T 

10 - 

20 - 

30 - 

40 - 

50 - 

60 - 


HOSTS 

193.30.20.10 193.30.20.11 193.30.20.12 193.30.20.13 


New-Style 

Broadcast 


(received) (received) (received) 


(collision!) 


ARP for 

ARP for 

ARP for 
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Figure 1: Classical Broadcast Storm 
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Figure 2: Poor Ethernet Configuration 



Figure 3: Better Ethernet Configuration 
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An Update on UNIX Standards Activities 

Shane P. McCarron 

NAPS International 
August 1, 1988 


This is the third in a series of reports on 
standards bodies relating to the UNIX 
community. Before I start, I would like to 
take a couple lines to thank all of those readers 
who were kind enough to drop me a line of 
either criticism or encouragement; both are 
greatly appreciated. In the future please feel 
free not only to comment on the articles here, 
but also on standards issues. I am more than 
happy to try and answer any of your questions 
either individually or through this column. 

To business: the most important item to 
report (from my perspective) is that the 
USENIX Association has formed a Standards 
Watchdog Committee. The charter of this 
group is to keep an eye on as many of the 
standards efforts as possible, and report the 
progress of those efforts back to the member¬ 
ship. In addition, the group will be looking for 
important or contentious decisions, and trying 
to determine a USENIX position where it 
seems appropriate. The group will also be 
looking to you, the members, for input. 
Everyone has opinions, and the Watchdog 
Committee, through its standards committee 
representatives, can serve as a channel to get 
your ideas to the appropriate groups or can 
put you in contact with the appropriate peo¬ 
ple. For more information, please contact: 

John S. Quarterman 
Texas Internet Consulting 
701 Brazos, Suite 500 
Austin, TX 78701 

(512) 320-9031 

jsq@usenix.org, uunet!usenix!jsq 

As always, the standards bodies have been 
pretty busy during the past quarter. Busy, that 
is, in standards body terms. There is often a 
great deal of heat, but very little light. I have 
remarked in the past that these committees 
can take a long time to complete things. 


P1003.0 - The POSIX Open Systems 
Environment Guide 

The IEEE 1003.0 working group met on 
July 12 & 13, 1988 in Denver, Colorado. The 
purpose of this meeting was to have the group 
members, who had volunteered during the 
March meeting to work on certain portions 
(sub-groups) of the POSIX Open Systems 
Environment guide document, present their 
material for review and critique by the group. 
This was accomplished on day 1 and the 
morning of day 2. The sub-groups that were 
discussed included: 

1. Operating System 

2. Database Management 

3. Data Interchange 

4. Network Services 

5. User Interface 

6. Languages 

7. Graphics 

The remainder of the meeting focused on 
goals and objectives for the next meeting in 
October. There was strong consensus within 
the group that the next goal should be a very 
rough draft document. Volunteers were 
assigned to each sub-group above with the 
purpose of putting into narrative form the 
material that had been presented. It was also 
agreed that distribution of this draft prior to 
the October meeting would be essential in 
order to allow for good, well thought-out 
discussion during the meeting. 

The group has targeted October, 1989 as a 
goal for beginning the balloting process. This 
is aggressive, but possible, assuming that the 
effort between meetings can be maintained at 
its present level. 

Overall, the meeting was very productive 
and is drawing more participation from a good 
cross-section of vendors and users. 
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P1003.1 

The big news this month is, of course, that 
as of August 22nd the POSIX System Services 
Interface standard is complete. By the time 
you read this, final drafts should have been 
circulated to all of the POSIX working group 
members, and copies of that draft should be 
available from the IEEE office in New York. 
While you can obtain a copy of the final draft 
now, you would do well to wait for a couple of 
months and pick up a real, hard-bound version 
of the standard from the IEEE. To order a 
copy of the final draft, contact: 

IEEE Standards Office 

345 E. 47th St. 

New York, NY 10017 

(212) 705-7091 

Since the last installment in this series, the 
1003.1 standard has gone through not one, and 
not two, but three more recirculations. As you 
may remember, the second recirculation was 
scheduled to take place in May, and it did. 
This one went as well as expected, and 
generated some excellent feedback. The 
changes from that recirculation were assem¬ 
bled and sent back to the balloting group for 
review at the end of June. As a result of that 
recirculation, there were yet more changes to 
the standard, and those changes had to be 
recirculated as well. The final recirculation 
took place at the end of July, and generated no 
substantial changes. At that point the 
standard was released to the Technical Editor 
for final copy editing, and has now been 
balloted on and approved by the IEEE 
Standards Board! 

This is actually good and bad. It is good 
for all the reasons you would suppose. It is 
bad because the standard is not perfect; there 
are things that shouldn’t be in it that are (e.g. 
some weird timezone stuff and readQ and 
writeQ functions that allow broken behavior), 
and things which should be in it but are not 
(like seekdirQ and telldirQ). Even though the 
standard is not perfect, at least we now have a 
foundation upon which additional documents 
can be based. In the future this standard will 
be extended and revised, but for now (in 
combination with Standard C), it’s the best 
thing we have for application portability. 


In the meantime, the . 1 working group has 
not been idle. Although the initial work on 
the Services Interface standard was completed 
some months ago, there are always new areas 
to work in. The following is information on 
developments where they occurred. 

Clean Up 

There are some issues that were not han¬ 
dled to the satisfaction of the working group in 
the first cut of the standard. A small group is 
working on sifting through the unresolved 
balloting objections (there were several) and 
identifying those items that can be rectified 
through modification to the standard. It turns 
out that many of the unresolved objections 
were very reasonable items, but were intro¬ 
duced too late in the process to be placed in 
the standard. Those items will be looked at 
and possibly added to the standard in a sup¬ 
plement. 

Language Independent Description 

While little progress has been made in this 
area by the . 1 working group, it turns out that 
there has been quite a bit of work done by 
other working groups and technical 
committees. The /usr/group technical 
committee on supercomputing, in particular, 
has produced a Fortran language description of 
the .1 interface. In the process they have 
come up with a number of items that can be 
used by the . 1 people to develop their language 
independent description. 

Terminal Interface Extensions 

The Working Group looked at the various 
requirements necessary for a terminal interface 
standard (a terminal interface standard is 
something like the Terminal Interface Exten¬ 
sions in the SVID, better know as 
curses/terminfo). The group determined that 
there is little or no way to get a single interface 
standard that will satisfy the needs of the 
entire community. Those people with bit 
mapped displays can do things better, and we 
should let them. Those people with block 
mode terminals have special needs that should 
not have to be addressed by otherwise portable 
applications. The majority of users that we 
are trying to satisfy, those with character based 
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terminals, have well defined needs that are 
already being addressed by existing practice. 

What’s the solution? Well, none was 
really proposed, but I would guess that the 
people in the bit mapped world are going to 
care a lot more about Open Look and Presen¬ 
tation Manager (bite my tongue) than they are 
about something based on terminfo or 
termcap. For the other 90 percent of the 
UNIX-using community, while terminfo & 
termcap may be what they are used to seeing, 
it is hardly attractive enough to make them sit 
up and take notice. They are looking for 
flashier, better, faster applications, and the 
traditional interface is not going to be enough. 
For application developers, the functionality 
which can be achieved via terminfo is fine but 
hardly adequate for building the products that 
the user community is coming to expect. 

I would guess that the POSIX committees 
will settle on some subset of the terminfo 
interface as the standard, and that no one will 
use it. Sure, it will be on every POSIX 
conformant system, but who cares? It is a 
lame interface, and someone will come up 
with a better one soon enough. 

New Archive Format 

As I mentioned previously, the ISO has 
asked P1003.1 to come up with a new archive 
format that will not have the deficiencies of tar 
or cpio and will be able to take the security 
concerns of the PI003.6 group into considera¬ 
tion (I assume that by this they mean access 
control lists, mandatory access controls, and 
the like). Little was done on this topic 
between meetings, but at the July meeting the 
committee discussed ways to extend the cpio 
archive format to take these things into 
consideration. While the technical details of 
this extension are clear, they are also boring. 
Suffice it to say that the filename field in the 
archive can be extended through a kludge and 
that it would be backward compatible. 

This met with mixed reactions, and I 
believe that in the end it will not be used. 
This discussion (popularly known as Tar Wars) 
has been very religious and contentious, and I 
don’t think that a format based on either will 
be able to get popular support from the work¬ 
ing group. There is now a small group of peo¬ 
ple (from both camps) working on another new 


format, and I am certain that they will come 
up with something for the October meeting. 

P1003.2 - Shell and Tools Interface 

This group is actually a little bit ahead of 
schedule. Forget all the nasty things I have 
said about their schedule being too tight and 
optimistic - they are actually going to do it! 
You’re not as impressed as I am, I can tell. 
Some people are just never satisfied. Okay, 
here’s some evidence for you. 

Functionality was frozen at the March 
meeting. This means that no additional 
commands or concepts could be added to the 
standard. It also means that the working 
group members were free to concentrate on the 
content of the draft, instead of looking at new 
proposals for additional commands all of the 
time. This has turned out to be very 
profitable; the draft has been cleaned up to the 
point where it can be submitted (to the work¬ 
ing and corresponding groups) for a mock 
ballot in September. A mock ballot is just that 
- a process during which the draft is picked 
apart as it would be in the balloting process, 
with changes submitted through formal ballot¬ 
ing objections. This may seem a little 
excessive, but it has proven effective in the 
past. 

Assuming that all goes well, and the objec¬ 
tions from the mock ballot are resolved at the 
October meeting, the group could go to a full 
ballot as early as January. A less optimistic 
scenario shows the group working on resolu¬ 
tion of the mock ballot for two full meetings, 
with the real ballot occurring in February or 
March. Either way, the group is on schedule 
for a full use standard before the end of 1989. 

In addition to this good news, there were 
a few key decisions made at the July meeting. 

This side of the Tar Wars is apparently at 
an end. There were two aspects to the war - 
user-program interface and actual archive 
format. The interface side of it seems to have 
been settled by the introduction of a command 
called pax (Latin for peace). This command 
will be able to read and write both types of 
archives and has an interface that is acceptable 
to both camps. While this has not been agreed 
upon by the balloting group, or even by the 
full working group, the interface is pretty 
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familiar, and I believe it will be approved with 
little change. 

The group also concentrated on trying to 
remove anything that might be considered 
implementation dependent from the draft. 
This included removing the octal modes from 
chmod, and the signal numbers from trap and 
kill. In their place go all of the mnemonic 
command line arguments that have been in 
those commands all along, but aren’t used by 
anyone. As a committee member I can see 
what they are trying to do, and even agree 
with it. As a user, however, I wish they would 
have placed requirements that, say, kill -9 
would always map to SIGKILL. At least that 
way I wouldn’t have to fix every shell script I 
have ever written. 

P1003.3 - Testing and Verification 

This working group is progressing well on 
its verification standard for 1003.1. They are 
planning to have a version to ballot in January 
or February of 1989. That would make the 
standard available just about the time that the 
major vendors are finishing their .1 
conformant implementations. 

The group has also started supplying 
liaison people to each of the other working 
groups. These people, with their experience 
writing a testing standard for .1, are proving 
very valuable in designing testable standards. 

New POSIX Work Items 

In addition to all of the committees you 
have heard about in past articles, there were 
several new working groups proposed to the 
PI003 steering committee. 

System Administration 

The committee recognizes the need for a 
standard interface to many of the system 
administration utilities that we are plagued 
with. While there was a considerable amount 
of skepticism exhibited from the members, the 
steering committee has agreed to let work 
progress on this topic. Consequently, a PAR 
was filed by Steve Carter of Bellcore, and the 
new working group will start meeting in 
October. 

This group has a lot of work ahead of 
them; the difficulties of designing standard 


interfaces to things like fsck and fsdb may 
prove impossible. Also, from an system imple¬ 
mentor standpoint, I would hate to have the 
administrative functions I can provide limited 
by something that a standards committee is 
going to generate based on existing practice. 
This is not an area in which there is a huge 
body of existing applications, so implementors 
should be allowed to innovate and improve if 
they like. 

On the other hand, the computer users of 
the world are probably pretty sick of having to 
learn a new way to enable printers on every 
system they purchase. For those people, hav¬ 
ing a standard is going to be a big win. This is 
one of those times when the saying “be careful 
what you wish for...” comes into play. The 
ultimate, generic system administration 
interface may prove to be so restricted or 
brain-dead that it is of no use to anyone. The 
. 1 standard was nearly that way. 

Networking 

Another new working group will be focus¬ 
ing on the services and service interfaces for a 
networked POSIX conformant system. While 
the exact charter and goals of this group are 
not fully established, what they are not trying 
to do is. They are not trying to overlap the 
work of the ISO-OSI committees, nor are they 
trying to supplant the work being done by 
IEEE 802. Their plan is to spend two years 
defining the services and service protocols, and 
maybe an additional year defining interfaces to 
those protocols. 

User Interface Commands 

If you have looked closely at the 1003.1 
and .2 standards, you will notice that there is 
nothing in either of them about User Interface. 
Well, you’re not alone, and someone is finally 
going to do something about it. A sub-group 
of the Shell and Tools committee has been 
formed to codify the interface of many of the 
classic UNIX commands (vi, ed, etc.). In addi¬ 
tion, the group will be defining the user 
interface aspects of those commands already in 
the .2 standard which have traditionally had 
user interfaces as well as their programmatic 
ones. 

This group is going to work somewhat in a 
vacuum - since there is no standard for 
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terminal interface, the user interfaces defined 
are not going to have a way, programmatically, 
of being put on the screen, terminfo will of 
course work for this, but it is not a standard. 
Hopefully the .1 committee can get a supple¬ 
ment out regarding this before the .2 sub¬ 
group finishes its work describing the utilities. 

X/Open 

The X/Open group is just about to release 
version 3 of the X/Open Portability Guide. 
This set of manuals is a must for any applica¬ 
tion developer or system implementor plan¬ 
ning on marketing products in Europe. Ver¬ 
sion 3 will encompass all of the .1 standard, 
but will not contain any of the items proposed 
in the latest drafts of .2 - that document is too 
immature. The XPG also has language 
definitions, database interface specifications, 
and many other things that a growing 
programmer needs in the UNIX world. 

NBS - Federal Information Processing 
Standard 

I have written about this in each issue of 
this report, and each time I say that it is 
almost here. Well, I am done making predic¬ 
tions. The Federal government has a shield 
that my crystal ball just refuses to penetrate. I 
have heard recently that the FIPS for the .1 
standard is within the Commerce department 
somewhere, but I have no proof. When it does 
finally come out, it will be based on a version 
of the standard that is almost a year out of 
date. Draft 12 of the .1 standard resembles 
the final standard about like a caterpillar 
resembles a butterfly. This is very 
unfortunate, as the vendors that are serious 
about selling computers to the Feds are going 
to have to conform to that standard, and not 
the real one. Note that while the NBS did try 
to jump the gun a little bit, they forced the . 1 
committee to work harder and faster. Without 
their encouragement the standard may well 
never have been finished. 

Of course, the NBS has indicated that they 
will start making the FIPS conform to the final 
standard just as soon as it is out (now, that 
means). But, given the amount of time it took 
them to get the first standard out the door, I’m 
not holding my breath. It could be deep into 


1989 before we see a revised FIPS hit the 
Federal Register’s list of announcements. 

In the meantime, the NBS is proceeding in 
its specification of other interim FIPS. Just 
until there are real standards in these areas, of 
course, we are going to see FIPS on Shell and 
Tools, User Interface, System Administration, 
Terminal Interface Extensions, and probably 
shoe lacing. The NBS people are very busy 
cranking out standards that Federal govern¬ 
ment departments can cite when generating 
bid requests. Unfortunately, in those cases 
where the committees aren’t far enough along 
yet, these standards are going to be based on 
the SVID. And if the SVID is used as a base 
document by the Feds, you can be sure that it 
will also be used by any standards committees 
that come along later and want to “codify 
existing practice.” Just another example of the 
Federal government guiding the standards 
community. 

The NBS is putting on a series of 
workshops this fall to address some of these 
issues, and get input from the community. 
The first of these workshops, a seminar on 
“POSIX and other Application Portability 
Profile Standards” will be September 22nd and 
23rd. For more information, contact Debbie 
Jackson at (301) 975-3295. She will be happy 
to send you registration materials, as well as 
give you information about future workshops 
being put on by the National Bureau of 
Standards. 

X3J11 - ANSI C Language Standard 

This standard is pretty important to every¬ 
one in the UNIX community. Unfortunately, 
that means that everyone has to get involved 
in the development of it, and that takes time. 
The document has now entered its third public 
comment period (July 1st -► August 31st). 
From what I gather, the committee will be 
very reluctant (read “it will never happen”) to 
make any substantive changes to the standard 
as a result of this period. What they are look¬ 
ing for is affirmation from the public that the 
changes made in round two were adequate to 
remove most of the outstanding objections. 

The good news here is that the noalias 
keyword has been removed from the draft. 
This was a very contentious issue, and was 
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introduced very late in the process. In 
simplest terms, noalias would allow the 
programmer to specify that the program, for 
that statement, would do exactly what it was 
supposed to do. Pretty silly, when you get 
right down to it. Anyway, its gone now - like 
a bad dream. 

In addition, a number of simple editorial 
changes were made. Most of these are 
transparent, and just made the standard a little 
more readable. Unfortunately, it is still a 
standard written by programmers, for 
programmers, and is a little hard to read. 
There is even rumor of a x3speak program, 
like the valspeak of a few years ago, about to 
come out in comp.sources.misc. This would 
take any prose and render it senseless through 


the addition of legalese. My advice to future 
readers of the standard is this: Don’t go into 
the water alone. Use the buddy system, and 
take a reader’s guide with you. 

Assuming all goes well at the September 
meeting, the ANSI C Language Standard 
should be published later this year. 

Well, that’s about it for this month. 
Remember, keep those cards and letters com¬ 
ing to: 

Shane P. McCarron 
NAPS International 
117 Mackubin St., Suite 6 
St. Paul, MN 55102 

(612) 224-9239 
ahby@bungia.mn.org 


Future Events 


EUUG Autumn Conference 
Estoril, Portugal, Oct. 3-7 

C++ Miniconference 
Denver, CO, Oct. 17-21 

The Program Chair is Andrew Koenig of 
AT&T. See page 3. 

Large Installation 
Systems Administration II 
Monterey, CA, Nov. 17-18 

The Program Chair is Alix Vasilatos of 
MIT’s Project Athena. See page 6. 

Japan UNIX Society 

Osaka, Nov. 11-15, Conference & Exhibition 
Toyko, Dec. 7-8, UNIX Fair ’88 

For both events, contact: Ms. Hiroko 
Tsunoda, Japan UNIX Society, 2-12-505 
Hayabusa-cho, Chiyoda-ku, Tokyo 102, 
+ 81-3-234-5058 


USENIX 1989 Winter Technical Conference 
San Diego, Jan. 30-Feb. 3,1989 

See page 5. 

EUUG Spring Conference 
Brussels, Apr. 10-14,1989 

See page 7. 


Long-term USENIX & EUUG Schedule 

Jun 12-16 ’89 Hyatt Regency, Baltimore 

Sep 18-22 ’89 Vienna, Austria 

Jan 22-26 ’90 Omni Shoreham, Washington, DC 

Apr 23-27 ’90 Munich, W. Germany 

Jun 11-15 ’90 Marriott Hotel, Anaheim 

Jan 21-25 ’91 Dallas 

Jun 10-14 ’91 Opryland, Nashville 

Jan 20-24 ’92 Hilton Square, San Francisco 

Jun 8-12’92 Marriott, San Antonio 
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USENIX Association 

(A Delaware Non-Stock Corporation) 

By-Laws* 

November 14, 1983 


Article 1: Activities 

1.1 Activities 

To achieve its purposes, the Corporation may: 

1.1.1 Meetings 

Conduct general meetings, discussion groups, 
forums, panels, lectures and other similar 
programs concerned with the development, 
exchange and communication of research and 
technological information and ideas pertaining 
to UNIX and UNIX-related computer systems. 

1.1.2 Publications 

Publish through its Newsletter and other publi¬ 
cations the results of its members investiga¬ 
tions and other information relevant to the 
purposes of the Corporation. 

1.1.3 Software Distribution 

Collect software and distribute said software to 
its members for use on their systems. 

1.1.4 License Verification 

Verify licenses of members for the purpose of 
administering the services of the Corporation. 

1.1.5 Other Activities 

Establish and promote other activities 
consistent with its purpose for the benefit of its 
members. 

Article 2: Definitions 

2.1 Defined Terms 

As used herein, the following terms shall have 
the meanings set forth below: 


2.1.1 The Corporation 

USENIX ASSOCIATION, a Delaware non-profit, 
non-stock corporation. 

2.1.2 Member’s Representative 

The employee or principal of a Member 
designated to serve as that Member’s official 
spokesman at any function of the Corporation 
and to cast that Member’s vote on all matters 
as to which the Member may have the right to 
vote. 

2.1.3 Voting Member 

Any Member who has been granted voting 
rights by Section 3.8. 

Article 3: Membership 

3.1 Classes of Membership 

Four classes of membership are provided. 
Benefits and qualifications for each class shall 
be determined by the Board of Directors. 

3.1.1 Student Member 

Any full time student is eligible to become a 
Student Member. 

3.1.2 Individual Member 

Any person who or organization which has a 
bona fide interest in the purposes of the 
Corporation is eligible to become an 
Individual Member. 

3.1.3 Institutional Member 

Any person who or organization which has a 
bona fide interest in the purposes of the 
Corporation is eligible to become an Institu¬ 
tional Member. 


t There have been several inquiries recently about the 
Association’s By-Laws. Here they are! -PHS 
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3.1.4 Supporting Member 

Any person who or organization which has a 
bona fide interest in the purposes of the 
Corporation is eligible to become a Supporting 
Member. 

3.2 Application for Membership 

An Organization or person desiring to become 
a Member shall submit a written membership 
application to the Corporation, addressed to 
the Secretary or his designated assistant. The 
completed application shall provide such infor¬ 
mation as shall from time to time be 
prescribed by the Board of Directors. 

3.3 Qualification as Member 

The Board of Directors shall establish 
procedures for review of each membership 
application. The applicant shall be notified of 
approval or rejection within thirty days after 
receipt of application. 

3.4 Obligations of all Members 

Each Member shall abide by the By-Laws and 
the rules and regulations of the Corporation as 
they may from time to time appear. All 
Members shall respect licensing obligations. 

3.5 Grounds for Loss of Membership 

A Member shall lose his membership within 
thirty days after receiving written notice from 
the Secretary that the Board shall have 
determined that the Member has failed to 
abide by the By-Laws or rules and regulations 
of the Corporation (such notice to state the 
basis for revocation of membership). 

3.6 Appeal 

Within ninety days of the receipt of notice 
sent pursuant to section 3.5, the recipient 
Member may appeal in writing (addressed to 
the President) to the Board of Directors to 
have the notice set aside. The only bases upon 
which such appeal may be made shall be: 

3.6.1 Invalid Grounds 

Proof satisfactory to the Board that the 
ground(s) set forth in the notice is (are) not 
valid, or 


3.6.2 Extenuating Circumstances 

A reasonably detailed statement of extenuating 
circumstances. The Board of Directors shall 
act upon an appeal within ninety days of its 
receipt and shall notify the appellant in writing 
of its decision within thirty days thereafter. 

3.7 Withdrawal 

A member may voluntarily withdraw from the 
Corporation at any time by giving written 
notification to the Secretary signed by the 
Member or Member’s Representative of the 
desire to so withdraw. Such withdrawal shall 
become effective upon receipt thereof by the 
Secretary. 

3.8 Rights of Members 

The right to vote for the election of members 
of the Board of Directors and officers and to 
vote on all issues is conferred solely upon 
Individual, Institutional and Supporting 
Members. Only a Voting Member or 
Member’s Representative shall be eligible to be 
a member of the Board of Directors or to hold 
elective office in the Corporation. 

3.9 Membership Dues 

The amount of dues to be paid by members of 
the Corporation shall be set by the Board of 
Directors. Dues shall be due and payable on a 
schedule set by the Board. 

Article 4 : Directors 

4.1 Powers 

All corporate powers shall be exercised by the 
Board of Directors, except as otherwise 
expressly provided by law or by the Certificate 
of Incorporation or by these By-Laws, but the 
directors shall act only as a Board and the 
individual directors shall have no power as 
such. Among such powers are: 

4.1.1 Corporate Policy 

The Board of Directors shall develop, 
determine and prosecute corporate policy. 
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4.1.2 Decisions of Members 

The Board of Directors shall interpret and 
implement the decisions of the Members. 

4.1.3 Budget 

The Board of Directors shall approve the 
Corporation’s annual budget and engage an 
accounting firm to examine the Corporation’s 
financial records and to prepare all necessary 
tax returns and information statements. 

4.1.4 Vacancies 

The Board of Directors shall fill all vacancies 
in any office or on the Board of Directors for 
the unexpired term of the previous holder of 
such office or seat on the Board of Directors, 
provided that any officer or director so elected 
shall be subject to removal by the Members 
and the Board of Directors shall not have any 
power to reelect any officer or director who 
may have been removed by the Members. If 
there is a vacancy in the office of the 
President, the Vice President shall assume that 
office and the Board of Directors shall fill the 
thus vacated office of Vice President. 

4.2 Number, Term of Office and 
Qualification 

The number of directors of the Corporation 
shall be eight. The Corporation’s President, 
Vice President, Secretary and Treasurer shall 
automatically become directors when elected 
to their office. In addition to the 
aforementioned officers, the Board of Directors 
shall have four other directors. Any eligible 
person may be reelected as a director one or 
more times. The term of office of each direc¬ 
tor shall begin at the Annual Meeting follow¬ 
ing his election and end at the Annual Meeting 
of the next even numbered year. The term of 
office of any director may be terminated at any 
time, with or without cause, by an affirmative 
vote of 2/3 of the votes cast by Members enti¬ 
tled to vote and who shall have voted thereon, 
but in no case shall an officer or director be 
removed unless 1/3 of the total membership 
entitled to vote casts votes in favor of the 
removal. 


4.3 Resignations 

Any Director may resign at any time, in writ¬ 
ing, by notifying the Board of Directors or the 
President or the Secretary of the Corporation. 
Such resignation shall take effect at the time 
therein specified, and, unless otherwise 
specified, the acceptance of such resignation 
shall not be necessary to make it effective. 

4.4 First Meeting 

Each duly elected Board of Directors shall 
hold its first meeting for the purpose of organi¬ 
zation and the transaction of other business, if 
a quorum be present, without notice of such 
meeting, on the same day and at the same 
place as the Annual Meeting next occurring 
after the election of said Board of Directors or 
as soon as practicable after such Meeting. 

4.5 Regular and Special Meetings 

Meetings of the Board of Directors shall be 
held at such places, within or without the State 
of Delaware, and times as may be fixed from 
time to time by resolution of the Board of 
Directors. The President or the Secretary may 
call, and upon written request signed by any 
three directors the Secretary shall call, special 
meetings of the Board of Directors. Any 
Meeting of the Board of Directors may be held 
within or without the State of Delaware, as 
designated in the notice or waiver of notice of 
such meeting. 

4.6 Notice of Meetings 

Notice of meetings of the Board of Directors 
shall be in writing, signed by the President or 
the Secretary, and shall be sent to each direc¬ 
tor by mail addressed to his last known 
address, being placed into the mail at least ten 
days before the time designated for such meet¬ 
ing. 

4.7 Waiver of Notice 

Any meeting of directors and any action other¬ 
wise properly taken thereat shall be valid if 
notice of the time, place and purposes of such 
meeting shall be waived in writing before, at 


26 


September/October 1988 


Volume 13, Number 5 



;login: 


or after such meeting by all directors to whom 
timely notices were not sent as provided in 
these By-Laws. 

4.8 Consent 

Any other provisions of these By-Laws to the 
contrary notwithstanding, any action required 
or permitted to be taken at any meeting of the 
Board of Directors or of any committee may 
be taken without a meeting, if prior to such 
action a written consent thereto is signed by 
all members of the Board or of such 
committee, as the case may be, and such 
written consent is filed with the minutes of 
proceedings of the Board of Directors. 

4.9 Quorum 

Four directors in office, personally present, 
shall be necessary and sufficient to constitute a 
quorum for the transaction of business at any 
meeting of the Board of Directors, but a 
smaller number may adjourn any such meeting 
to a later date. Notice of such adjourned 
meeting shall be given by mail to each director 
not present at such meeting, the notice being 
addressed to his last known address and placed 
into the mail at least ten days before the time 
designated for such meeting. 

4.10 Action by Majority Vote 

Except as otherwise expressly required by law 
or by these By-Laws, the act of 4 or more 
directors who are a majority of the directors 
present at a meeting at which a quorum is 
present shall be the act of the Board of Direc¬ 
tors. 

4.11 Vote to Fill Vacancies 

Any vacancy in the Board of Directors may be 
filled for the unexpired term, in accordance 
with section 4.1.4 by a majority vote of the 
remaining directors, though less than a 
quorum. 

4.12 Submission of Matter to Mail Vote of 
the Members 

The Board of Directors may submit any 
matter to a mail vote of the Members, when 
required or deemed advisable or desirable by 
the Board of Directors. Any such mail vote 
shall be pursuant to Article 9. The 


membership vote shall be binding upon the 
Board of Directors only if at least 1/3 of all 
members entitled to vote upon the issue shall 
vote. If less than 1/3 of voting members vote, 
the issue may be decided by the Board of 
Directors. 

Article 5: Officers 

5.1 Officers 

The officers of the Corporation shall be a 
President, a Vice President, a Secretary and a 
Treasurer, each to have such duties or func¬ 
tions as are provided in these By-Laws or as 
the Board of Directors may from time to time 
determine. One person may not hold any two 
or more of the foregoing offices. 

5.2 Nomination and Elections 

Nominations and elections shall be in 
accordance with Article 7. 

5.3 Term 

The term of office of each officer shall begin at 
the Annual Meeting following his election and 
end at the Annual Meeting of the next even 
numbered year. The term of any officer may 
be terminated at any time, with or without 
cause, by an affirmative vote of 2/3 of the 
votes cast by Members entitled to vote and 
who shall have voted thereon, but in no case 
shall an officer be removed unless 1/3 of the 
total membership entitled to vote casts votes 
in favor of the removal. 

5.4 Resignations 

Any officer may resign at any time, in writing, 
by notifying the Board of Directors or the 
President or the Secretary of the Corporation. 
Such resignation which automatically includes 
resignation from the Board of Directors, shall 
take effect at the time therein specified, and, 
unless otherwise specified, the acceptance of 
such resignation shall not be necessary to 
make it effective. 

5.5 Vacancies 

A vacancy in any office caused by death, resig¬ 
nation, removal, disqualification or other cause 
may be filled in accordance with section 4.11 
for the unexpired portion of the term by the 
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Board of Directors at any regular or special 
meeting. 

5.6 The President 

The President shall be the chief executive 
officer of the Corporation and shall have 
general supervision over the affairs of the 
Corporation, subject, however, to the control 
of the Board of Directors. He shall, if present, 
preside at all Annual Meetings, and at all 
meetings of the Board of Directors. In 
general, he shall perform all the duties incident 
to the office of the chief executive officer of a 
corporation and such other duties as are pro¬ 
vided for in these By-Laws and as from time 
to time may be assigned to him by the Board 
of Directors. 

5.7 The Vice President 

At the request of the President, or in his 
absence, the Vice President shall perform all 
the duties of the President and in so acting 
shall have all the powers of and be subject to 
all the restrictions upon the President. The 
Vice President shall perform such other duties 
as may from time to time be assigned to him 
by the President or by the Board of Directors. 

5.8 The Secretary 

The Secretary shall act as Secretary of all 
meetings of the Board of Directors, and of the 
Members of the Corporation, and shall keep 
the minutes thereof in the proper book or 
books to be provided for that purpose; he shall 
cause all notices required to be given by the 
Corporation to be duly given and served; he 
shall have charge of the other books, records 
and papers of the Corporation; he shall cause 
the reports, statements and other documents 
required by law to be properly kept and filed; 
he shall see that a current list of Members is 
maintained; he shall be responsible for 
processing membership applications; and he 
shall, in general, perform all the duties 
incident to the office of Secretary and such 
other duties as may from time to time be 
assigned to him by the Board of Directors or 
by the President. 


5.9 The Treasurer 

The Treasurer shall collect, and keep account 
of all moneys received and expended for the 
use of the Corporation; he shall deposit sums 
received by the Corporation in the name of 
the Corporation in such depositories as shall 
be approved by the Board of Directors. 

Article 6: Committees 

6.1 Committees 

By a majority vote, the Board of Directors 
may from time to time create or terminate 
standing and ad hoc committees and may 
determine the names of such committees and 
the qualification of the members of such 
committees; and, to the extent permitted by 
law, may delegate the powers and duties of the 
Board of Directors to such other committees, 
and, to such extent, may otherwise determine 
such powers and duties. The Board of Direc¬ 
tors may elect the members of such 
committees or may authorize the President 
and/or any other officer or officers to select the 
members of any such committee. 

Article 7: Election of Officers and 
Directors 

7.1 Nominations 

No later than nine months preceding the 
Annual Meeting in every even numbered year, 
the Board of Directors shall notify Members of 
the names of Voting Members to serve as a 
Nominating Committee. Such Committee 
shall present names of candidates for each 
Officer and for the Directors to the Members 
for election. Nominations shall close six 
months after the date of notification to the 
members of the composition of the Nominat¬ 
ing Committee. Nominations for each Office 
and Directorship may also be made by any 
five members. All nominations must bear the 
signature of at least five Voting Members. 

7.2 Elections 

Whenever the Officers or Directors are to be 
elected by the Members, they shall be elected 
by a plurality of the votes by mail ballot by the 


28 


September/October 1988 


Volume 13, Number 5 



;login: 


members entitled to vote in the election. 
Within four weeks following the close of nomi¬ 
nations, the Secretary shall cause to be 
compiled and mailed to all Voting Members a 
ballot which includes a brief summary of the 
qualifications of each candidate. The balloting 
shall be conducted in accordance with the 
provisions of Article 9. The newly elected 
Officers and Directors will be informed within 
one week of the results of the election and the 
date their term begins. 

Article 8: Annual Meeting 

8.1 Date of Meeting 

The date of the Annual Meeting shall be 
established by the Board of Directors. At least 
one month in advance of the meeting date the 
Board of Directors will notify the Members of 
the date and time of the Annual Meeting. 

Article 9: Voting 

9.1 Mail Voting 

All voting by the Members shall be conducted 
by mail. 

9.2 Eligibility 

Except as provided by law, every Voting 
Member of record as of the date of entry of a 
ballot into the mails shall be entitled to one 
vote. 

9.3 Voting Procedures 

On all questions to be submitted to a ballot of 
the Members, the Secretary shall designate a 
date for the ballot to be placed in the mails. 
Each ballot must bear a due date not less than 
two nor more than four weeks after the date of 
entry of the ballot into the mails. The ballots 
will be counted within two weeks following the 
due date. No ballots received after that time 
will be counted, regardless of postmark. The 
results of the vote will be announced 
immediately to the Board of Directors. 

9.4 Authentication of Ballots 

The Board of Directors shall establish 
procedures to authenticate the ballots. 


Article 10: Contract, Checks, Drafts, 
Bank Accounts, etc. 

10.1 Execution of Contracts 

The Board of Directors, except as otherwise 
provided in these By-Laws, may prospectively 
or retroactively authorize any officer or 
officers, agent or agents, in the name and on 
behalf of the Corporation to enter into any 
contract or execute and satisfy any instrument, 
and any such authority may be general or 
confined to specific instances. Any contract 
whose dollar value exceeds an amount set by 
the Board of Directors must be specifically 
authorized for that value by the Board of 
Directors. 

10.2 Checks, Drafts, etc 

All checks, drafts and other orders for pay¬ 
ment of money out of the funds of the 
Corporation, if less than a limit established by 
the Board of Directors, shall be signed on 
behalf of the Corporation by any one officer, 
normally the Treasurer. For amounts equal to 
or greater than the established limit, said 
instruments shall be signed by two Officers. 

10.3 Deposits 

The funds of the Corporation not otherwise 
employed shall be deposited from time to time 
to the order of the Corporation in such banks, 
trust companies or other depositories as the 
Board of Directors may select. 

Article 11: Books and Records 

11.1 Books and Records 

There shall be kept at a place to be designated 
by the Treasurer correct books of account of 
all the business and transactions of the 
Corporation. If the books and records are to 
be kept at a place other than the principal 
place of employment of the Treasurer, 
Treasurer shall notify the President and 
Secretary in writing of the location of said 
books and records. 
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Article 12: Seal 

12.1 Seal 

The Board of Directors shall provide a 
corporate seal which shall be in the form of a 
circle and shall bear the full name of the 
Corporation and the year of its incorporation. 

Article 13: Amendments of By-Laws 

13.1 Amendments by Members 

These By-Laws, or any one or more of the 
provisions thereof, may be amended by chang¬ 
ing, altering, suspending, supplementing or 
repealing the same, by an affirmative vote of 
2/3 of the votes cast by Members entitled to 
vote and who shall have voted, but only in 
accordance with a proposed amendment duly 
published and mailed to Voting Members at 
least thirty days prior to the date of entry of 
the ballot into the mails. In no case shall an 
amendment by members be carried by a vote 
of less than 1/3 of total membership entitled to 
vote. Conduct of voting shall be in accord 
with Article 9. 

13.2 Amendments by Directors 

These By-Laws or any one or more of the 
provisions thereof may, except for this article, 
also be amended by changing, altering, 
suspending, supplementing or repealing the 
same; by the Board of Directors at any duly 
constituted regular or special meeting of the 
Board of Directors. Such an amendment shall 
require an affirmative vote by at least two- 
thirds of the entire Board of Directors. Any 
amendment of these By-Laws by the Board of 
Directors shall at all times be subject to 


rescission by the Members. The Board of 
Directors shall not have any power to readopt 
any amendment which may have been 
rescinded by the Members. When the Board 
of Directors proposes a change to the By-Laws, 
written notice of the proposed change, includ¬ 
ing the vote, the proposed change, and 
pertinent reasons for the change must be 
distributed by the Secretary to the Members by 
first-class mail. Negative responses to the 
proposed change from the Members shall be 
directed to the Secretary. Thirty calendar days 
after the mailing the Secretary will tabulate the 
responses from Members, and the amendment 
will take effect if fewer than 25 percent of the 
Members, of mailing record date, have 
objected. If 25 percent or more object, the 
amendment shall not take effect until the 
members have voted on rescinding the by-law. 
The vote to rescind shall be in accordance 
with section 13.1. 

Article 14: Compensation of Officers 
and Directors 

14.1 Compensation of Officers and 
Directors 

No part of the income of the Corporation shall 
inure to the benefit of any Member, Director, 
or Officer of the Corporation, or any private 
individual (except that reasonable compensa¬ 
tion may be paid for services rendered to or 
for the Corporation affecting one or more of 
its purposes), and no Member, Director, of 
Officer of the Corporation or any private 
individual shall be entitled to share in the 
distribution of any of the assets on dissolution 
of the Corporation. 
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Staff Changes 


After the San Francisco meeting, Emma 
Reed, the Association’s Membership Secretary, 
retired. She and her husband, Al, have moved 
from the Bay Area to California’s Central Val¬ 
ley, near Fresno. After years of frenetic ques¬ 
tions from members, we hope Emma and Al 
have a long and peaceful retirement. We will 
miss the twinkle in her eye. 

The Association’s new receptionist is Mrs. 
Eeva McFeely. 


The Association has lured away the Jour¬ 
nals Manager from the University of 
California Press. On August 1, Ellie Young 
(usenixlellie) became Deputy Executive Direc¬ 
tor. She will act as Peter’s left brain, and will 
be responsible for, among other things, .login: 
and the various workshop proceedings. She 
will also be in charge of some special projects, 
for example, the Association’s public relations 
efforts and the ongoing FaceSaver project. 


Publications Available 


The following publications are available 
from the Association Office. Prices and 
overseas postage charges are per copy. 
California residents please add applicable sales 
tax. Payment must be enclosed with the order 
and must be in US dollars payable on a US 
bank. 


The EUUG Newsletter, which is published 
four times a year, is available for $4 per copy 
or $16 for a full-year subscription. 

The July 1983 edition of the EUUG 
Micros Catalog is available for $8 per copy. 

We hope to have EUUG tapes and confer¬ 
ence proceedings available shortly. 


Conference and Workshop Proceedings 


Overseas Mail 


Meeting 

Location 

Date 

Price 

Air 

Surface 

USENIX 

San Francisco 

Summer ’88 

$20 

$25 

$5 

C++ Workshop 

Santa Fe 

November ’87 

20 

25 

5 

Graphics Workshop IV 

Cambridge 

October ’87 

10 

15 

5 

USENIX 

Wash. DC 

Winter ’87 

10 

25 

5 

Graphics Workshop III 

Monterey 

December ’86 

10 

15 

5 
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4.3BSD Manuals 


The USENIX Association now offers all 
members of the Association the opportunity to 
purchase 4.3BSD manuals.* 

The 4.3BSD manual sets are significantly 
different from the 4.2BSD edition. Changes 
include many additional documents, better 
quality of reproductions, as well as a new and 
extensive index. All manuals are printed in a 
photo-reduced 6"x9" format with individually 
colored and labeled plastic “GBC” bindings. 
All documents and manual pages have been 
freshly typeset and all manuals have “bleed 
tabs” and page headers and numbers to aid in 
the location of individual documents and 
manual sections. 

A new Master Index has been created. It 
contains cross-references to all documents and 
manual pages contained within the other six 
volumes. The index was prepared with the aid 
of an “intelligent” automated indexing 
program from Thinking Machines Corp. along 
with considerable human intervention from 


Mark Seiden. Key words, phrases and 
concepts are referenced by abbreviated docu¬ 
ment name and page number. 

While two of the manual sets contain 
three separate volumes, you may only order 
complete sets. 

The costs shown below do not include 
applicable taxes or handling and shipping from 
the publisher in New Jersey, which will 
depend on the quantity ordered and the 
distance shipped. Those charges will be billed 
by the publisher (Howard Press). 

Manuals are available now. To order, 
return a completed “4.3BSD Manual 
Reproduction Authorization and Order Form” 
to the USENIX office along with a check or 
purchase order for the cost of the manuals. 
You must be a USENIX Association member. 
Checks and purchase orders should be made 
out to “Howard Press.” The manuals will be 
shipped to you directly by the publisher. 


Manual _ Cost* 

User’s Manual Set (3 volumes) $25.00/set 

User’s Reference Manual 
User’s Supplementary Documents 
Master Index 

Programmer’s Manual Set (3 volumes) $25.00/set 

Programmer’s Reference Manual 
Programmer’s Supplementary Documents, Volume 1 
Programmer’s Supplementary Documents, Volume 2 

System Manager’s Manual (1 volume) $10.00 

* Not including postage and handling or applicable taxes. 


4.2BSD Manuals are No Longer Available 


t Tom Ferrin of the University of California at San Francisco, a former member of the Board of Directors of the USENIX 
Association, has overseen the production of the 4.2 and 4.3BSD manuals. 
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4.3BSD Manual Reproduction Authorization and Order Form 

This page may be duplicated for use as an order form 

USENIX Member No.:_ 

Purchase Order No.:_ 

Date:_ 

As a USENIX Association Member in good standing, and pursuant to the copyright notice as 
found on the rear of the cover page of the UNIX®/32V Programmer’s Manual stating that 

“Holders of a UNIX®/32V software license are permitted to copy this document, or any portion of it, as 
necessary for licensed use of the software, provided this copyright notice and statement of permission 
are included,” 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and provide 
me with such copies of the Berkeley 4.3BSD Manuals as I may request. 

Signed:_ 

Institution (if Institutional Member):_ 

Ship to: Billing address, if different: 

Name:_ Name:_ 


Phone: __ Phone:__._ 

The prices below do not include shipping and handling charges or state or local taxes. All pay¬ 
ments must be in US dollars drawn on a US bank. 

4.3BSD User’s Manual Set (3 vols.) _ at $25.00 each = $__„ 

4.3BSD Programmer’s Manual Set (3 vols.) _ at $25.00 each = $_ 

4.3BSD System Manager’s Manual (1 vol.) __at $10.00 each = $.___ 

Total ___ $_ 

[ ] Purchase order enclosed; invoice required. 

(Purchase orders must be enclosed with this order form.) 

[ ] Check enclosed for the manuals: $__ 

(Howard Press will send an invoice for the shipping and handling charges and applicable taxes.) 

Make your check or purchase order out to “Howard Press” and mail it with this order form to: 

Howard Press 
c/o USENIX Association 
P.O. Box 2299 
Berkeley, CA 94710 


for office use: m.v.: 


check no.: 


amt. rec’d: 
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Local User Groups 

The USENIX Association will support local user groups by doing an initial mailing to assist the 
formation of a new group and publishing information on local groups in ;login:. At least one member 
of the group must be a current member of the Association. 


CA - Fresno: the Central California UNIX Users 
Group consists of a uucp -based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

brent@CSUFresno.edu or csufresibrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 875-8755 

csufresigordon (209) 298-8393 

CA - Los Angeles: the Los Angeles UNIX Group 
meets on the 3 rd Thursday of each month in 
Redondo Beach. 

Drew Bullard (213) 535-1980 

{ucbvax,ihnp4}! trwrb!bullard 

MarcRies (213) 535-1980 

{decvax,sdcrdcf} !trwrb!ries 

CO - Boulder: meets monthly at different sites. 

Front Range UNIX Users Group 
USENIX Association Exhibit Office 
5398 Manhattan Circle 
Boulder, CO 80303 

John L. Donnelly (303) 499-2600 

{boulder,usenix) Ijohnd 

FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 

FL - Melbourne: the Space Coast UNIX Users 

Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 

Alex Stover (305) 724-3962 

codas!lola!als 

Bill Davis (305) 242-4449 

bill@ccd.harris.com 

FL - Orlando: the Central Florida UNIX Users 

Group meets the 3 rd Thursday of each month. 

Mike Geldner (305) 862-0949 

codas! sunfla! mike 


Ben Goldfarb (305) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (305) 869-2462 

{codas,attmail} Imikel 


FL - Tampa Bay: the Tampa UNIX Users Group 
meets the l sl Thursday of each month, alternately in 
Largo and Tampa. 

Scott Stone (813) 974-3307 

uflorida!usfvax2!stone, stone@usf.edu 

Bill Hargen 

{codas,usfvax2)!pdn!hargen 

(813) 530-8655 

George W. Leach 
uunet!pdn!reggie 

(813) 530-2376 

GA-Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 

P.O. Box 12241 

Atlanta, GA 30355-2241 

Marc Merlin 

Mark Landry 

(404) 442-4772 
(404) 365-8108 

MI - Detroit/Ann Arbor: meets 
of each month in Ann Arbor. 

the 2 nd Thursday 

William Bulley 
web@applga.uucp 

(313) 995-6211 

Rich McGill 
rich@oxtrap.uucp 

(313) 971-5950 

Steve Simmons 
scs@lokkur.uucp 

(313) 426-8981 

MI - Detroit/Ann Arbor: dinner 
Wednesday of each month. 

meetings the l sl 

Linda Mason 
michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 

(313) 855-4220 


MN - Minnetonka: meets the 1 st Wednesday of 
each month. 

UNIX Users of Minnesota 
545 Ashland Avenue #3 
St. Paul, MN 55102 
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Scott Anderson (612) 688-0089 

scott@questar.mn.org 

MO - St. Louis: 

St. Louis UNIX Users Group 
Plus Five Computer Services 
765 Westwood, 10A 
Clayton, MO 63105 

Eric Kiebler (314) 725-9492 

ihnp4!plus5!sluug 

NE - Omaha: meets on the 2 nd Thursday of each 
month. 

/usr/group nebraska 
P.O. Box 44112 
Omaha, NE 68144 

Sukan Makmuri (402) 422-8367 

ihnp4!ugn!root 

New England - Northern: meets monthly at 

different sites. 

Emily Bryant (603) 646-2999 

Kiewit Computation Center 
Dartmouth College 
Hanover, NH 03755 

David Marston (603) 883-3556 

Daniel Webster College 
University Drive 
Nashua, NH 03063 

decvax! dartvaxlnneuug-contact 

NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian (609) 452-6261 

Dept, of Computer Science 
Princeton University 
Princeton, NJ 08544 

pep@Princeton.EDU 

NY - New York City: 

Unigroup of New York 
G.P.O. Box 1931 
New York, NY 10116 

Ed Taylor (212) 513-7777 

{attunix,philabs} !pencom!taylor 

New Zealand: 

New Zealand UNIX Systems User Group 
P.O. Box 13056 
University of Waikato 
Hamilton, New Zealand 


OK - Tulsa: 

Pete Rourke 
$USR 

7340 East 25 lh Place 
Tulsa, OK 74129 

PA - Philadelphia: the UNIX SIG of the 
Philadelphia Area Computer Society (PACS) meets 
the morning of the 3rd Saturday of each month at 
the Holroyd Science Building, LaSalle University. 

G. Baun, UNIX SIG 
c/o PACS 
Box 312 

La Salle University 
Philadelphia, PA 19141 

{inhp4,cbosgd,rutgers)! {bpa,cbmvax}! 
temvax!pacsbb!{gbaun,whutchi) 

TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 

TX - San Antonio: the San Antonio UNIX Users 
(SATUU) meets the 3 rd Wednesday of each month. 

Jeff Mason (512) 494-9336 

Hewlett Packard 

14100 San Pedro 

San Antonio, TX 78232 

gatech!petro!hpsatb!jeff 

WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
6641 East Mercer Way 
Mercer Island, WA 98040 

uw-beaver!tikal!camco!bill 

Washington, D.C.: meets the 1 st Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 333 
Vienna, VA 22180 

Samuel Samalin (703) 448-1908 
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USENIX Association 

P.O. Box 2299 
Berkeley, CA 94710 


First Class Mail 


FIRST CLASS MAIL 
U.S. POSTAGE PAID 
Berkeley, CA 
Permit No. 993 


C++ Conference Program 

Broadcast Storms, Nervous Hosts, & Load Imbalances 

UNIX Standards Activities 
Ordering GNU Software 
USENIX By-Laws 

Change of Address Form 

Please fill out and send the following form through the U.S. mail to the Association Office at the address above. 

Name:_Member #:__ 

OLD:_NEW:_ 

Phone:_ 


uucp : {uunet,ucbvax}! 



